Use and Operation of poll(2)

Use and Operation of poll(2)

The IRIX version of poll() allows a process to wait for events of different types to occur on any combination of devices, files, and STREAMS (see the poll(2) and select(2) reference pages). It is possible for multiple processes to be waiting for events on the same device.

It is up to you as the designer of a driver to decide which of the events that are documented in poll(2) are meaningful for your device. Other requested events simply never happen to the device.

Much of the complexity of poll() is handled by the IRIX kernel, but the kernel requires the assistance of any device driver that supports poll(). The driver is expected to allocate and hold a pollhead structure (declared in sys/poll.h) for each minor device that it supports. Allocation is simple; the driver merely calls the phalloc() kernel function. (The pfxstart() entry point is a suitable place for this call; see "Entry Point start()".)

There are two phases to the operation of poll(). When the system function is called, the kernel calls the pfxpoll() entry point to find out if any requested events are pending at this time. If the kernel finds any event s pending (on this or any other polled object), the poll() function returns to the user process. Nothing further is required.

However, when no requested event has happened, the user process expects the poll() function to block until an event has occured. The kernel cannot implement this delay by repeatedly testing for events; that would be too inefficient. The kernel must rely on device drivers to notify it when an event has occurred.

Use of pollwakeup()

A device driver that supports pfxpoll() is required to notify the kernel whenever an event that the driver supports has occurred. The driver does this by calling a kernel function, pollwakeup(), passing the pollhead structure for the affected device, and bit flags for the events that have taken place. In the event that one or more user processes are blocked in a poll(), waiting for an event from this device, the call to pollwakeup() will release the sleeping processes. For an example, see "Calling pollwakeup()".

Use of pollwakeup() Without Interrupts

If the device in question does not support interrupts, the driver cannot support poll() unless it can somehow get control to discover an event and report it to pollwakeup(). One possibility is that the driver could simulate interrupts by setting a succession of itimeout() delays. On each timeout the driver would test its device for a change of status, call pollwakeup() when an event has occurred; and schedule a new delay. (See "Waiting for Time to Pass".)